NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c++/363

Internet Message Format | 1996-08-06 | 3.6 KB

From: [e-mail] (Nathan Sidwell)
Message-ID: <[e-mail]>
X-Original-Date: Fri, 9 Feb 1996 15:48:24 GMT
Path: in1.uu.net!bounce-back
Date: 10 Feb 96 05:01:38 GMT
Approved: [e-mail]
Newsgroups: comp.std.c++
Subject: Nesting scope resolution
Organization: Inmos
X-Newsreader: TIN [version 1.2 PL2]
X-Auth: PGPMoose V1.1 PGP comp.std.c++
    iQBFAgUBMRwm1uEDnX0m9pzZAQEeEQF6AlwOKh3yx8p7Eph/IylC5VX/vP+n6+bM
    z/6MnGl4VzY6Y2Q1I29XWX3ar/qqDXry
    =fsUG

Is the line tagged //B legal?

class One
{
  unsigned  scalar;
public:
  void func(int);
};
class Two : public One
{
protected:
  typedef One Parent;
};
class Three : public Two
{
protected:
  typedef Two Parent;
public:
  void func(int);
};

void Three::func(int i)
{
  One::func(i);                 //A
  Parent::Parent::func(i);      //B
}

I believe lines A and B are equivalent, but some compilers say yes and some
say no. Visual C++, Borland C++ and cfront reject it. G++ and
SGI C++ accept it.

The construction Parent::Parent::func seems a natural way of getting
at the grandparent methods, without actually knowing the name of the
grandparent class.

The draft ANSI standard has this to say

5.1 defines primary expressions, one of which is an id-expression,

id-expression:
    unqualified-id
    qualified-id

qualified-id:
    nested-name-specifier template<opt> unqualified-id

unqualified-id:
    identifier
    ...

a function call is a postfix expression (5.2), which is

postfix-expression:
    primary-expression
    postfix-expression(expression-list<opt>)
    ...

the nested-name-specified is defined in 7.3.1.1

nested-name-specifier:
    class-or-namespace-name :: nested-name-specifier<opt>

class-or-namespace-name:
    class-name
    namespace-name

it also adds (para 3) that 'The search of a name after a :: locates only named
members of a namespace or class.'

So the expression 'Parent::Parent::func(i)' looks like a
postfix-expression constructed of
primary-expression['Parent::Parent::func'] ( expression-list['i'] )

the primary-expression 'Parent::Parent::func'
looks like a qualified-id of
nested-name-specifier['Parent::Parent::'] unqualified-id[func]

and the nested-name-specifier 'Parent::Parent::' is
class-or-namespace-name['Parent'] :: nested-name-specifier['Parent::']

of which the nested-name-specifier is again
class-or-namespace-name['Parent'] ::

now the question is, is Parent (a typedef) considered a class-name?

section 7.1.3 has this to say about typedefs. 'A typedef-name is thus
a synonym for another type'. Classes are definatly types, so Parent is
a synonym for a class. Para 3 of 7.3.1.1 tells us which typedef to use
after the respective ::. And of course, if Parent wasn't considered a
class-name, I wouldn't be able to write the simple Parent::func, to
get a superclass's method (and we know that works).

QED

Another way of looking at it is that inside a class member function,
member names have an implicit '<ClassName>::' prepended to them.
so writing Parent::func() (which is definiatly ok) is shorthand for
Three::Parent::func(), which isn't a million miles from what I've actually
written.

So which is right?

nathan

--
Nathan Sidwell                         Holder of the Xmris home page
Chameleon Architecture Group at SGS-Thomson, formerly Inmos
http://www.pact.srf.ac.uk/~nathan/                  Tel [phone]
[e-mail] or [e-mail] or [e-mail]
---
[ comp.std.c++ is moderated.  Submission address: [e-mail].
  Contact address: [e-mail].  Moderation policy:
  http://reality.sgi.com/employees/austern_mti/std-c++/policy.html. ]